[Polly] Introduce PhaseManager and remove LPM support #125442
Merged
+2,700
−4,460
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
|
[like] Karthika Devi C reacted to your message:
…________________________________
From: Eli Friedman ***@***.***>
Sent: Monday, February 3, 2025 1:40:45 AM
To: llvm/llvm-project ***@***.***>
Cc: Karthika Devi C (QUIC) ***@***.***>; Review requested ***@***.***>
Subject: Re: [llvm/llvm-project] [Polly] Introduce PhaseManager and remove LPM support (PR #125442)
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
@efriedma-quic<https://github.com/efriedma-quic> requested your review on: #125442<#125442> [Polly] Introduce PhaseManager and remove LPM support.
—
Reply to this email directly, view it on GitHub<#125442 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXW3Q47JNLHXTDSBTI26WP32N3CJ3AVCNFSM6AAAAABWK6V7R6VHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJWGE2TINRYGYYDGOA>.
You are receiving this because your review was requested.Message ID: ***@***.***>
|
Member
Author
|
FYI, @rahulana-quic @tobiasgrosser For some reason I cannot add you as reviewers, but feel free to start a review. |
…nager' into users/meinersbur/polly_PhaseManager
Contributor
|
Hi @Meinersbur |
Member
Author
|
OK, please signal your LGTM when you are ready |
Contributor
|
Thanks for your patience @Meinersbur. |
kartcq
reviewed
Apr 9, 2025
Meinersbur
changed the base branch from
users/meinersbur/polly_NPM-ScopInliner
to
users/meinersbur/polly_CodePreparation
…einersbur/polly_CodePreparation
…inersbur/polly_CodePreparation
Meinersbur
added a commit
that referenced
this pull request
Oct 31, 2025
Use a common function for the non-boilerplate code shared between LPM and NPM as done by most other passes already. ScalarEvolution is not actually used. Patch extracted out of #125442 requested by #125442 (comment)
Base automatically changed from
users/meinersbur/polly_CodePreparation
to
main
October 31, 2025 18:23
llvm-sync bot
pushed a commit
to arm/arm-toolchain
that referenced
this pull request
Oct 31, 2025
…M (#140419) Use a common function for the non-boilerplate code shared between LPM and NPM as done by most other passes already. ScalarEvolution is not actually used. Patch extracted out of #125442 requested by llvm/llvm-project#125442 (comment)
…ersbur/polly_PhaseManager
…einersbur/polly_PhaseManager
DEBADRIBASAK
pushed a commit
to DEBADRIBASAK/llvm-project
that referenced
this pull request
Nov 3, 2025
) Use a common function for the non-boilerplate code shared between LPM and NPM as done by most other passes already. ScalarEvolution is not actually used. Patch extracted out of llvm#125442 requested by llvm#125442 (comment)
boomanaiden154
added a commit
that referenced
this pull request
Nov 4, 2025
This reverts commit e987ab1. This broke premerge: 1. https://lab.llvm.org/staging/#/builders/192/builds/9521 2. https://github.com/llvm/llvm-project/actions/runs/19054182009 Notably this did not break inside the PR. Not exactly sure why. I realize that there is a lot of test churn here, but they're largely in polly where commit frequency is much lower, so a reapply of the patch should be clean.
Contributor
|
I've reverted this in a22d1c2. It broke premerge after landing. It did not break inside this PR, likely because LLVM is not tested on polly changes. Sorry for the churn. I know there's a lot of changed files here. Hopefully it's not too big of a deal given polly's commit frequency is lower than most of the rest of the project. |
Member
Author
|
Sorry for that. I tested it locally and it did pass. I was also taking a look on the various Polly buildbot configurations (https://lab.llvm.org/buildbot/#/workers/28, https://lab.llvm.org/buildbot/#/workers/74) but unknowingly to me, their sponsor retired them. |
ckoparkar
pushed a commit
to ckoparkar/llvm-project
that referenced
this pull request
Nov 6, 2025
) Use a common function for the non-boilerplate code shared between LPM and NPM as done by most other passes already. ScalarEvolution is not actually used. Patch extracted out of llvm#125442 requested by llvm#125442 (comment)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Instead of relying on any pass manager to schedule Polly's passes, add Polly's own pipeline manager which is seen as a monolithic pass in LLVM's pass manager. Polly's former passes are now phases of the new PhaseManager component.
Relying on LLVM's pass manager (the legacy as well as the New Pass Manager1) to manage Polly's phases never was a good fit that the PhaseManager resolves:
Polly passes were modifying analysis results, in particular RegionInfo and ScopInfo. This means that there was not just one unique and "definite" analysis result, the actual result depended on which analyses ran prior, and the pass manager was not allowed to throw away cached analyses or prior SCoP optimizations would have been forgotten. The LLVM pass manger's persistance of analysis results is not contractual but designed for caching.
Polly depends on a particular execution order of passes and regions (e.g. regression tests, invalidation of consecutive SCoPs). LLVM's pass manager does not guarantee any excecution order.
Polly does not completely preserve DominatorTree, RegionInfo, LoopInfo, or ScalarEvolution, but only as-needed for Polly's own uses. Because the ScopDetection object stores references to those analyses, it still had to lie to the pass manager that they would be preserved, or the pass manager would have released and recomputed the invalidated analysis objects that ScopDetection/ScopInfo was still referencing. To ensure that no non-Polly pass would see these not-completely-preserved analyses, all analyses still had to be thrown away after the ScopPassManager, respectively with a BarrierNoopPass in case of the LPM.
The NPM's PassInstrumentation wraps the IR unit into an
llvm::Anyobject, but implementatons such as PrintIRInstrumentation call llvm_unreachable on encountering an unknown IR unit, such as SCoPs, with no extension points to add support. Hence LLVM crashes when dumping IR between SCoP passes (such as-print-before-changedwith Polly being active).The new PhaseManager uses some command line options that previously belonged to Polly's legacy passes, such as
-polly-print-detect(so the option will continue to work). Hence the LPM support is incompatible with the new approach and support for it is removed.PRs from this patch series:
Footnotes
When Chandler Carruth announced working on the NPM, I talked to him about supporting Polly's use cases. His response was "passes must adhere to the constraints of the pass manager". ↩